Description

This PR removes the manual approval workflow for functional tests and simplifies the CI architecture by using GitHub's native fork approval mechanism.

Changes Made

Removed Files

• .github/workflows/functional-tests-approval.yaml - The manual approval workflow that gated functional tests
• .github/actions/download-pr-data-artifact/ - The composite action that retrieved PR numbers from approval workflow artifacts

Modified Files

• .github/workflows/functional-test-cloud.yaml:
  • Replaced workflow_run trigger (dependent on "Approve Functional Tests") with direct pull_request trigger
  • Removed workflow_run-specific environment variables and logging
  • Removed "Download PR data artifacts" and "Set PR context (workflow_run)" steps
  • Updated job if conditions to use pull_request instead of workflow_run

Benefits

1. Simplified architecture - Direct pull_request trigger instead of workflow_run chain
2. Better PR visibility - Test status now appears directly in PR checks section (previously was a separate workflow run)
3. Native fork protection - Uses GitHub's built-in "Require approval for outside collaborators" setting instead of custom environment-based approval
4. Faster feedback - No intermediate approval workflow step for org members
5. Reduced maintenance - Fewer custom actions and workflow coordination logic

Configuration Required

GitHub organization/repository settings have been configured:

• Settings → Actions → General → Fork pull request workflows set to require approval for outside collaborators

This ensures org members' PRs run automatically while external contributors' PRs wait for maintainer approval using GitHub's native UI.

Type of change

• This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Radius (issue link optional).

Fixes: N/A

Contributor checklist

Please verify that the PR meets the following requirements, where applicable:

• An overview of proposed schema changes is included in a linked GitHub issue.
  • Yes
  • Not applicable
• A design document PR is created in the design-notes repository, if new APIs are being introduced.
  • Yes
  • Not applicable
• The design document has been reviewed and approved by Radius maintainers/approvers.
  • Yes
  • Not applicable
• A PR for the samples repository is created, if existing samples are affected by the changes in this PR.
  • Yes
  • Not applicable
• A PR for the documentation repository is created, if the changes in this PR affect the documentation or any user facing updates are made.
  • Yes
  • Not applicable
• A PR for the recipes repository is created, if existing recipes are affected by the changes in this PR.
  • Yes
  • Not applicable